There are two typical call transfer use-cases: (a) an attended transfer (also known as consultative transfer) and (b) semi-attended transfer (also known as blind transfer).
Attended transfer satisfies the following telephony use-case. User A (the Transferor to be) and User B (the Transferee to be) are in an established session. User A decides to transfer User B to User C (the Transfer Target). User A initiates the transfer (e.g. by pressing the “transfer key” a first time), which causes User A to put User B on hold. Then, User A makes a call to User C. User A waits for User C to answer and announces to User C the pending call transfer. User A completes the transfer (e.g. by pressing the “transfer key” a second time). In this transfer scenario, User A expects to be out of both calls—the “original” call between User A and User B as well as the “consultation” call between User A and User C immediately following the transfer completion (e.g., after pressing the “transfer key” a second time). It is also expected that User B gets connected to User C.
Semi-attended transfers satisfy a similar yet slightly different telephony use-case. Specifically, User A (the Transferor to be) and User B (the Transferee to be) are in an established session. User A decides to transfer User B to User C (the Transfer Target). User A initiates the transfer (e.g. by pressing the “transfer key” a first time). User A puts User B on hold. Then, User A makes a call to User C. User A waits to hear ringback (or any other early media) from User C to make sure that he/she has dialed the correct address of User C. User A completes the transfer (e.g. by pressing the “transfer key” a second time) before User C has answered the call. In other words, the transfer is completed by User A before User C answers the call. User A expects to be out of both calls—the “original” call between User A and User B as well as the “consultation” call between User A and User C immediately following the transfer completion (e.g., after pressing the “transfer key” a second time). It is also expected that User B hears ringback (or early media) from User C and that User B gets connected to User C as soon as User C answers the call.
While implementation of the attended transfer is well covered by the industry standards (e.g., IETF RFC 5589, the entire contents of which are hereby incorporated herein by reference) and, thus, well understood and adopted in the industry with good inter-vendor interoperability, the situation is quite different with semi-attended transfer.
Semi-attended transfer has stumped the industry for years, primarily because the procedures of the attended call transfer cannot be followed for the semi-attended transfer. In fact, IETF RFC 3891, the entire contents of which are hereby incorporated herein by reference, explicitly disallows replacing an early dialog on the User Agent Server (UAS) side. Specifically, IETF RFC 3891 provides, “If the Replaces header field matches an early dialog that was not initiated by this UA, it returns a 481 (Call/Transaction Does Not Exist) response to the new INVITE, and leaves the matched dialog unchanged.”
The primary reason that RFC 3891 disallows using INVITE with Replaces for replacement of an early dialog on the UAS side is that this does not work well in the presence of call forking to several endpoints.
As a result, an attempt to use the attended transfer procedures in the case of the semi-attended transfer results in a call failure in a standards-compliant SIP implementation. Many vendors ignore this aspect of the standard while others comply to the standard. The result is interoperability problems in solutions with mixed vendor SIP implementations.
Some vendors ignore the limitations of the Replaces mechanism imposed by RFC 3891 and apply the mechanism (e.g., the same one used by the attended transfer) to the semi-attended transfer. This yields a simple implementation that works in environments where forking is disabled (e.g., where only a single SIP endpoint is allowed to be registered against an address-of-record (AoR) at any point in time). Since this approach is not universally adopted, the solution has inherent interoperability problems in scenarios where the transferor and the transfer target use SIP endpoints from different vendors.
Other vendors have opted for the approach where the consultation call gets cancelled by the transferor and the transferee is instructed by the transferor to make a new call to the transfer target. This suffers from the following problems: (a) the transfer target may notice an unusual “stutter” in the alerting signal (because of the consultation call being cancelled and new call being presented to the transfer target) and (b) an inherent race condition exists between the transfer target answering the call and the transferor cancelling it which may result in a transfer failure.